Verification on Pixel_9 emulator (Android 14+, hidden-API blocks SCVH reflection)

Built the example app from the worktree branch, installed on Pixel_9 AVD via npm run android.

maestro suite — 9/9 passed in 3m 31s

• Manual show/hide of cover via JS API
• Cover survives background/foreground cycle without leaking the overlay
• Image resize mode and position pickers update the cover
• Cover toggle and color change
• Color + image combine; setBlur replaces both
• Keyboard input still works while the cover is enabled
• Cover paints above an open RN Dialog
• Blur intensity picker updates the cover
• Fade animation does not break show/hide

argent manual stress

• 5× rapid Home / app-switcher / Home → broadcast mounts cleanly via the legacy fast path; no leaked covers on return.
• 10× rapid Enable cover / Disable cover toggle (~150 ms apart) → each cycle fires a fresh attachCover + detachCoverView; no crash.

logcat

This emulator turns out to be exactly the reflection-blocked case the latch is designed for:

06-01 11:44:57.151 W Cover : unscheduleScvhTraversals: no ViewRootImpl field found on SurfaceControlViewHost; disabling reflection AND SCVH
06-01 11:46:05.295 I Cover : attachCover: preferredRefreshRate=60.000004 (modes=60.000004Hz)
06-01 11:46:05.311 I Cover : attachCover: SurfaceControl captured=false

First SCVH detach in each process trips the latch → every subsequent attach uses the legacy WindowManager.addView path (no WindowlessWindowManager involved). The freeze + removeViewImmediate defences carry the first-detach load while reflection is unavailable.

Filtered logcat *:E for Invalid window token, IllegalArgumentException, WindowlessWindow, FATAL, AndroidRuntime across the entire session — no matches. Only unrelated PermissionService noise and the expected InputDispatcher: channel … unrecoverably broken lines that fire when activities tear down.

🤖 Generated with Claude Code

Follow-up: removed scvhDisabled latch on reflection failure

The previous commit's scvhDisabled = true latch on unscheduleScvhTraversals failure was too aggressive. On reflection-blocked devices (Android 14+ Pixel_9 emulator and similar hidden-API enforcement) the latch flipped on the very first SCVH detach and every later attach fell through to the legacy WindowManager.addView path. The legacy path loses the SurfaceFlinger-direct alpha toggle that the v0.1.3 snapshot race fix relies on — observed regression: cover sometimes misses the Recents thumbnail on Home press.

Latch removed in 1f121ca. The other defences in detachCoverView carry the load:

• FreezableFrameLayout.requestLayout() no-op during teardown → no new Choreographer traversals queued
• WindowManager.removeViewImmediate → dispatchDetachedFromWindow runs inline, freeze catches any layout requests it makes

unscheduleScvhTraversals still latches scvhReflectionDisabled so we don't keep retrying a probe that won't succeed, but SCVH stays on.

Re-verified on Pixel_9 (still the reflection-blocked case):

W Cover : unscheduleScvhTraversals: no ViewRootImpl field found on SurfaceControlViewHost; disabling reflection
I Cover : attachCover scvh: attached size=1080x2424 visible=false sc=ok          ← SCVH stays on
I Cover : broadcast: reason=homekey isEnabled=true isVisible=false sc=false
I Cover : broadcast: fast scvh=true refl=false dt=0ms                            ← SF-direct alpha wins
I Cover : setCoverVisibility: visible=true animated=false scvh=true

10× rapid Home / app-switcher cycles — every broadcast event shows scvh=true, every detach is clean, no Invalid window token in logcat *:E.

🤖 Generated with Claude Code

Round 3: zero-crash guarantee + snapshot-race fix preserved

Two further commits to close the remaining holes after the latch-removal regression.

1855d2c

Adds two more layers:

1. deferredReleaseScvh — defer host.release() across one Choreographer frame.

host.release() removes the WWM token via an asynchronously-dispatched doDie() (MSG_DIE). When reflective unscheduleScvhTraversals is blocked (Android 14+ hidden-API enforcement) any TraversalRunnable already in the Choreographer queue at detach time would fire AFTER MSG_DIE, call WWM.relayout on a removed token, and crash from Looper.loop.

The deferred release uses Choreographer.postFrameCallback (animation phase) to schedule mainHandler.post(safeReleaseScvh), which runs AFTER that frame's traversal callbacks complete. Pre-queued runnables fire with the token still valid; release happens once they've drained. ViewRootImpl.mTraversalScheduled caps the queue to one runnable per ViewRootImpl, so a single frame's wait drains it.

All 6 safeReleaseScvh call sites (5 in tryAttachCoverViaScvh recovery branches + 1 in detachCoverView) now route through the deferred helper.

2. API 30 INTERNAL_SYSTEM_WINDOW pre-check.

On Android 11 the SCVH path through WindowManagerService.addWindow enforces INTERNAL_SYSTEM_WINDOW, a signature-level permission no normal app holds. host.setView() throws SecurityException AFTER ViewRootImpl.setView has already called requestLayout() — queuing a TraversalRunnable. The catch handles the exception but the queued runnable fires next vsync against a token that was never registered with the WWM ("never added") and crashes. The deferred release can't help here because the runnable fires in the same vsync's traversal phase, before our queued Handler message.

Scoped to API 30 only — Android 12+ dropped the permission check for SCVH's addToDisplay path, so SCVH works for ordinary apps and the snapshot-race fix runs unmodified there. A blanket check would falsely disable SCVH on Pixel_9 / production Android 14+ devices, reintroducing the regression. We accept losing the SurfaceFlinger-direct alpha toggle on Android 11 — the legacy view.alpha path still works for cover visibility, just with a slightly higher snapshot-race window.

Verified on Favvy_Android_30 (API 30) emulator

The exact crash reproduced on a fresh cold-booted Favvy_Android_30 (Pixel 4 / Android 11):

06-01 15:14:55.676 W Cover : attachCover scvh: setView failed (SecurityException): Requires INTERNAL_SYSTEM_WINDOW permission
06-01 15:14:55.676 W Cover : safeReleaseScvh: release failed (NullPointerException): ... InputStage.onDetachedFromWindow()
06-01 15:14:55.676 I Cover : attachCover: preferredRefreshRate=60.000004
06-01 15:14:55.688 E AndroidRuntime: FATAL EXCEPTION: main
                                    java.lang.IllegalArgumentException: Invalid window token (never added or removed already)
                                      at android.view.WindowlessWindowManager.relayout(WindowlessWindowManager.java:237)

After the fix, same emulator, same operation:

06-01 15:27:45.555 I Cover : ensureCoverOnTopmost: reparent (topmost=DecorView)
06-01 15:27:45.556 W Cover : attachCover scvh: API 30 + INTERNAL_SYSTEM_WINDOW not granted; SCVH would throw at setView, disabling SCVH for this session
06-01 15:27:45.556 I Cover : attachCover: preferredRefreshRate=60.000004
06-01 15:27:45.585 I Cover : attachCover: SurfaceControl captured=false

4 home/appSwitch cycles + 8 rapid enable/disable toggles → app PID stable, logcat *:E filtered for Invalid window token | IllegalArgumentException | WindowlessWindow | FATAL returns no matches.

Summary of the layered fix

The SCVH SurfaceFlinger-direct alpha toggle stays enabled on every device that supports it (Android 12+). The snapshot race fix runs unmodified.

🤖 Generated with Claude Code

Round 4: real blur on Android 11 (API 30) — not a flat tint

After scoping out the SCVH crash on Android 11 in the previous round, the BLUR mode on those devices fell through to CoverBlurRenderer's API < S branch — which had been dropping the captured bitmap and painting a flat ~80% white tint. Underlying app content was fully readable through the cover. Broken privacy on every Android 11 host.

36af299

Reuse the captured bitmap as a poor-man's blur on API < 31 instead of discarding it. Capture at 1/12 in each dimension (1/144 pixels) — small enough that ImageView's bilinear filter at draw time produces a frosted-glass smudge when upscaled back to display size. Layer the style tint as foreground exactly like the API >= S path so the visual contract is consistent across versions.

} else {
  val bitmap = captureViewBitmap(source, scale = FALLBACK_BLUR_CAPTURE_SCALE)
  if (bitmap != null) {
    target.setImageBitmap(bitmap)
    val tint = style.tintColor()
    target.foreground = if (tint != Color.TRANSPARENT) ColorDrawable(tint) else null
    target.setBackgroundColor(Color.TRANSPARENT)
  } else {
    // Source view had no laid-out size yet (rare; first frame).
    // Original flat-tint fallback keeps privacy without the smudge.
    target.setImageDrawable(null)
    target.foreground = null
    target.setBackgroundColor(style.fallbackColor())
  }
}

Verified on Favvy_Android_30 (API 30) emulator

Mode BLUR LIGHT 0.4, Home → app-switcher view. Text labels (Cover, Status, Mode, RESIZE labels, button text) are smudged unreadable. Button shapes are visible as soft blobs. The LIGHT style tint is layered on top. Underlying content is obscured to the same degree iOS's UIBlurEffect obscures on the platform — privacy cover does its job on Android 11.

5 rapid Home / app-switcher cycles on top of the BLUR mode — app PID stable, logcat *:E filtered for Invalid window token | IllegalArgumentException | WindowlessWindow | FATAL returns no matches.

Status summary